Skip to content

Improve argument error messages of ext/standard #5198

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed

Conversation

kocsismate
Copy link
Member

@kocsismate kocsismate commented Feb 22, 2020

3 notes:

  • There were some cases in this PR as well when a message was not easy to convert to the new format (e.g. in case of the Input string contains NULL bytes)
  • The zend_argument_type_error() and zend_argument_value_error() macros had to be converted to a function, otherwise zend_exceptions.h should have been imported in way too many files (because of using zend_ce_type_error and zend_ce_value_error)
  • I'll update the tests later when the messages are finalized

@Girgias
Copy link
Member

Girgias commented Feb 22, 2020

For the null byte messages maybe something along the lines argument x must not contain any null bytes"?

@kocsismate kocsismate force-pushed the consistent-error-messages3-standard branch from 6eb6fb6 to 5d3efe5 Compare February 23, 2020 20:34
@kocsismate
Copy link
Member Author

kocsismate commented Feb 23, 2020

thanks @Girgias for the review! :) I've just addressed the comments and adapted the tests in a separate commit.

For the null byte messages maybe something along the lines argument x must not contain any null bytes"?

The problem is that currently, argument error messages follow the foo() expects argument ... format, that's why we can't use negative sentences like "must not ...". I think it's a bit problematic, but so far this error message is the only case when I couldn't come up with an at least ok-ish message.

@kocsismate kocsismate force-pushed the consistent-error-messages3-standard branch from 5d3efe5 to 61b8cdb Compare February 23, 2020 20:40
@Girgias
Copy link
Member

Girgias commented Feb 23, 2020

thanks @Girgias for the review! :) I've just addressed the comments and adapted the tests in a separate commit.

For the null byte messages maybe something along the lines argument x must not contain any null bytes"?

The problem is that currently, argument error messages follow the foo() expects argument ... format, that's why we can't use negative sentences like "must not ...". I think it's a bit problematic, but so far this error message is the only case when I couldn't come up with an at least ok-ish message.

How about foo() expects argument to not contain any null bytes compared to your proposed foo() expects argument to not contain null bytes? Seems slightly better but it is indeed kinda suboptimal.

@kocsismate kocsismate force-pushed the consistent-error-messages3-standard branch from 61b8cdb to a855326 Compare February 24, 2020 09:22
Copy link
Member

@Girgias Girgias left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me, it is maybe a bit annoying that every type error message needs to add to be of type in front of it but that isn't dramatic.

@php php deleted a comment from CatAnonymous Feb 24, 2020
@kocsismate kocsismate force-pushed the consistent-error-messages3-standard branch 4 times, most recently from 3f156a5 to 9d23da8 Compare February 26, 2020 15:24
@cmb69 cmb69 added the Feature label Mar 3, 2020
@nikic
Copy link
Member

nikic commented Mar 18, 2020

This looks pretty good, I think the final format turned out to be quite nice :)

@kocsismate kocsismate force-pushed the consistent-error-messages3-standard branch from e125baf to a31ecc8 Compare March 18, 2020 16:50
@php-pulls php-pulls closed this in bb6f374 Mar 18, 2020
@kocsismate kocsismate deleted the consistent-error-messages3-standard branch March 18, 2020 18:57
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants